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ABC is a software development tool designed to improve the 
performance of your Atari BASIC programs. It lets you enjoy 
the high speed and memory efficiency of compiled languages like 
FORTH and C, without leaving the familiar environment of your 
BASIC cartridge. 

1. 1 How Does It Work ? 

ABC stands for "A Basic Compiler.” A compiler is a program 
that accepts source code (your BASIC program) and translates it 
into another form, in this case a compact pseudo-code or 
P-code . Once compiled, this P-code can be executed by another 
program called a run- time i n terpreter . Both a compiler and an 
interpreter are included on your ABC disk. 

To compile a BASIC program with ABC, you must first SAVE the 
BASIC program on a disk. The ABC compiler reads your BASIC 
program off the disk and translates it into P-code, one line at 
a time. Then it permanently links a copy of the ABC 
interpreter to the P-code, and saves the compiled program as a 
binary disk file which can be loaded and executed like a 
machine-language program. The BASIC source file is unaffected. 

The benefits of using ABC include: 

Faster execution spee d. ABC-compiled programs run from four to 
twelve times faster than the original BASIC version, depending 
on the source code. This makes it possible to use Atari BASIC 
for professional game development and other speed-critical 
applications. 

Greater mem ory efficiency . The P-code produced by ABC is 
considerably more compact than tokenized BASIC. Numbers are 
stored in three bytes instead of the six required by the Atari 
floating-point routines. Additionally, the ABC interpreter 
requires only 4K of memory, about half that used by the BASIC 
cartridge. The result is a compiled program that requires much 
less memory overhead than the original BASIC version. 

No n-cartri dge environment . Compiled programs can be run 
withou t the BASIC cartridge! This allows access to the upper 
8K of memory in a 48K system, which is normally de-selected by 
the cartridge. 


- 3 - 







1.5 Purpose 0 f This Manual 


Source code protection . ABC P-code is a compressed and encoded 
version of the original source program which is very difficult 
to understand without detailed knowledge of the ABC run-time 
interpreter. For this reason, a BASIC program processed by ABC 
cannot be listed or disassembled and is extremely hard to 
"break." 

1.2 System Requirements 

To use the ABC software, your Atari computer system must 
include a minimum of 40K memory and at least one disk drive. 

You must also have the Atari Disk Operating System, DOS 2.OS, 
to create your working copy of the ABC disk. 

The memory required to run a compiled program depends on the 
size of the original BASIC source code, and may be little as 
16K bytes . 

1.3 Distributing Your Compiled Software 

No royalties or licensing fees are required to distribute 
software processed by ABC. However, we do require that your 
software bears the following notice: 

"Produced using copyrighted software products of Monarch Data 
Systems, Cochituate, MA 01778." 

Display the notice prominently on either the program title 
screen or in the documentation provided with the product. 
Failure to reproduce this notice may constitute a copyright 
infringement, 

1.4 Contents Of This Package 

Your ABC package should contain: 

A disk containing the ABC compiler, run-time interpreter 
and a relocation utility; 

— A label for your working copy of the ABC disk; 

This reference manual, and; 

— A user registration form. 

Please take the time to fill out and return the registration 
form. This will enable us to supply you with revisions and 
enhancements to the ABC system, and to keep you informed of new 
products as they become available. 


The ABC Reference Manual is intended to show you how to operate 
your ABC software. You should already be familiar with Atari 
BASIC programming and with Atari DOS 2.OS. 

1.6 References 

The following reference documents are published by Atari. 

Atari BASIC Reference Manual (CO14722) 

Atari Disk Operating System II Reference Manual (CO16347) 

Atari Techn ical Reference Notes (CO16355) 

Section 2 

Making A Working Copy 

You will get a "B OOT ERROR" message if you try to boot y our 
original ABC disk . The reason is that the original disk does 
not include a copy of DOS 2.OS. To obtain an operational 
version of ABC, you must first make a "working copy" of the 
original disk and write new DOS files on it so it will boot. 

Never remove the write-protect tab from your original ABC 
disk . This will help prevent accidental damage to the software. 

Use the following procedure to make a working copy of ABC: 

a. Remove all cartridges from your computer. 

b. Boot a disk containing Atari DOS 2.OS. When the menu 
appears, insert a blank disk into your drive and use option 
"I” to format the disk. 

c. Insert your original ABC disk and select DOS option "J" to 
copy it onto the freshly formatted disk. When the 
duplication is completed, remove the original ABC disk and 
store it in a safe place. 

d. Select DOS option "H" to write the Atari DOS files onto 
your working copy of ABC. Then remove the copy and put a 
write-protect tab on it to avoid accidents. 

e. Your working copy of ABC must bear a Monarch Data Systems 
copyright notice. A pre-printed disk label with the 
appropriate notice is included in your ABC package. 
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We chose not to copy-protect your original ABC disk so that you 
would be able to back it up conveniently. In re t urn for our 
consideration, we ask you not t o duplica te o r distribute the 
ABC software in any form except for the sole purpose of 
creating a single working copy for y o ur personal use . Any 
other duplication or distribution of the ABC software is a 
violation of Federal copyright laws. 

Section 3 

Compiling A BASIC Program 

A compiled program can only be as good as the original BASIC 
source. If your BASIC code has bugs in it, ABC will faithfully 
translate the bugs into P-code, resulting in incorrect 
operation at best and a total system crash at worst. Then 
you’ll have to return to your BASIC source, track down the bugs 
and re-compile. Always make sure you r BA SIC program is working 
properly before you try to compile it . 

Once you're satisfied with your source code, SAVE it onto a 
disk using a BASIC command in the form: 

SAVE "Dl:PROGRAM.BAS" 

Naturally, you can specify a different drive number if you 
want, with any legal file name or extender. The ”.BAS” 
extender is useful because it helps you tell the BASIC and 
compiled versions of your programs apart. 

The ABC compiler is supplied as an AUTORUN.SYS file that will 
execute whenever your working copy is booted on Drive #1. Use 
the following procedure to compile a SAVEd Atari BASIC program: 

a. Remove all cartridges from your computer. Turn on Drive #1 
and wait for the "BUSY” light to go out. 

b. Insert your ABC working disk into Drive #1 and turn on the 
computer. 

c. The ABC title screen and copyright notice will appear on 
your TV set or monitor. Approximately one second later, 
the system will begin reading the ABC run-time interpreter 
into memory. 

d. When the interpreter is loaded, the program will ask you to 
remove the ABC disk and insert the disk that contains your 
SAVED Atari BASIC program. 


e. ABC will next request the name of your BASIC source program 
(the one you are compiling). Respond with a drive 
specifier (Dl:, D2:, etc.) and the full file name, 
including any extensions. A default drive specifier of 
"Dl:” and a ".BAS" extension will be provided if they are 
not supplied by you. If your filename has no extender, 
include a trailing period ("PROGRAM.") to prevent ABC from 
trying to add the ".BAS" extender. 

f. You will now be asked to specify the name of the 
destination file. This file will eventually become the 
compiled version of your BASIC program. Again respond with 
a drive spec ifer and a full file name. The defaults are 
"Dl:" with a ".CMP" extender. 

g. ABC will immediately open a new disk file with the name you 
selected. It will then write a copy of the run-time 
interpreter into the new file. A temporary "scratch pad" 
file is also created on Drive #1 for ABC’s own use. 

(NOTE: In single-drive systems, the destination file is 

always written on the same disk as the source file. Make 
sure the disk is not write-protected or you will get an 
error message.) 

h. The compiler now begins to scan your original BASIC 
program. First, it displays the number of variables 
(symbols) used in your program, followed by the total 
number of program lines. Using this information, the 
compiler proceeds to convert each BASIC line into P-code. 
The progress of the compiler is indicated by displaying 
every 25th line number of the BASIC program, with 
intermediate lines represented by a single dot. 

i. After a successful compilation, ABC will display a 
"Compilation Completed" message. You will then be offered 
a choice via the console switches of whether to re-run the 
compiler (START), reboot the system (OPTION) or return to 
DOS (SELECT). To run the program you just compiled , return 
to DOS by pressing the SELECT key and use DOS option "L" to 
load the destination file, which will begin executing 
automatically. 
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Section 4 

B ASIC Programming Considerations 


4 


4.3 Simulating Floating-Point Numbers 


To achieve the high speed and efficiency of the ABC system, it 
was necessary t6 place a few limitations on the Atari BASIC 
code that can be compiled. Most programmers will find that 
these "limitations” aren’t very restricting at all — in fact, 
they may actually help to improve your programs by making you 
explore alternative methods of problem-solving. 

4.1 Integer Arithmetic 

Each constant and variable in an Atari BASIC program is stored 
in floating-point format, using six bytes of binary-coded 
decimal. Whenever you RUN a BASIC program, these numbers must 
be translated back and forth from floating-point to "straight” 
binary so that they can be used by the Atari operating system 
ROM. This constant translating and the general "laziness" of 
floating-point operations are the main reasons for the 
notoriously slow speed of Atari BASIC. 

ABC avoids the speed limitations of floating-point by using 
only integer (whole number) arithmetic. Values are stored as 
three bytes of "straight" binary, with a usable range of 
approximately -8 million to +8 million. 

Most Atari programs do not need floating point arithmetic . 
Games, graphics and systems software rarely employ fractions or 
complex mathematical functions. As a result, you may find that 
many of your favorite BASIC programs can be compiled with 
little or no alteration. And because of ABC’s wide usable 
number range, it’s possible to simulate almost any 
floating-point function using simple integer operators. 

4.2 Unsupported Functions 

Because ABC does not employ floating-point math, it will not 
accept a BASIC program that contains any of the following 
func tions: 

ATN CLOG COS EXP LOG 

RND SIN SQR 


You can partially compensate for ABC's lack of floating-point 
by scaling all of your intermediate results. For example, if 
you multiply a number by 100 before performing a division, you 
will obtain two significant digits after the "imaginary" 
decimal point in your answer. 

Suppose you need to divide 7 by 2, with an accuracy of two 
significant digits. In regular Atari BASIC, this would be 
coded as: 

ANSWER = 7/2 (evaluates to 3.50) 

In a BASIC program intended for compilation, you could use: 
ANSWER = INT((7*100)/2) 

which evaluates to 350 in both Atari and ABC-compiled BASIC. 

This method is not intended as a substitute for the convenience 
of automatic floating-point. But it should satisfy the limited 
need for fractions in the majority of games and systems 
programs. 

4.4 Simulating The RND() Function 

At first it may not seem obvious why RND() is included on the 
list of unsupported functions. In Atari BASIC, RND() returns a 
value that is less than one and greater than or equal to zero. 
This value cannot be represented by a whole number, and 
therefore requires floating-point. So if you need a random 
number in your ABC program, you'll have to find a way to obtain 
it without using RND(). 

Fortunately, the hardware provides a simple way to simulate the 
RND() function. The Atari operating system is constantly 
storing a new random integer between 0 and 255 into memory 
location 53770. Almost any random value can be obtained by 
PEEKing this location and scaling the result appropriately. 

To illustrate the technique, let's assign the memory address 
53770 to the variable RANDOM: 


RANDOM = 53770 
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Suppose your latest computer game needs a random value from 0 
to 9, inclusive. You could obtain it with the following 
expression: 

VALUE = INT(PEEK(RANDOM)*10/256) 

To obtain a value from 0 to 99 you could use: 

VALUE = INT(PEEK(RANDOM)*100/256) 

In the event that you want a random value greater than 255, you 
will have to break up the number into groups of one or two 
decimal digits. If, for instance, you need a value between 0 
and 999, you could get the "hundreds” digit with: 

HUNDS = INT(PEEK(RANDOM)*10/256) 

Now get the tens and ones digits together: 

OTHERS = INT(PEEK(RANDOM)*100/256) 

Combine the results: 

VALUE = HUNDS*100+OTHERS 


and the variable VALUE will contain a random number between 0 
and 999. 


4.5 Simulati 


ric Functions 


The simplest way to simulate an Atari BASIC trig function is to 
prepare a look-up table. You can either enter the table values 
in a DATA statement, use integer approximations to calculate 
the values at run-time, or use Atari BASIC to compute the 
values once and fill an array with the results. 


The essential trick is to convert each table element to a whole 
number by scaling it by an appropriate factor. If you need 
accuracy to two significant digits, you would multiply by 100; 
for three-digit accuracy, 1000, etc. Using the SIN() function 
as an example: 


VALUE = INT(1000*SIN(X)) 


Then SIN(0) becomes 0, SIN(45) becomes 707 (normally 0.707) and 
SIN(90) becomes 1000 (normally 1). 
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Now, suppose you have prepared tables of scaled SIN and COS 
values in arrays S() and C(), respectively, and you want to 
draw a circle of radius R at center point X and Y. The 
following instructions will accomplish this: 

100 FOR I = 0 TO 359 

110 PLOT X+R*S(I)/1000,Y+R*C(I)/1000 

120 NEXT I 

To generate a trig table at run-time you can make use of the 
trigonometric identities: 

sin(a+b) = sin(a)cos(b)+sin(b)cos(a) 
cos(a+b) = cos(a)cos(b)-sin(a)sin(b) 

By selecting the angle b as a constant and looking up its sine 
and cosine, you can iterate through all the angles by the 
increment of b and fill in an array with appropriately scaled 
values. 

4.6 Limited Size Of Constants 

Although the range of variables that can be handled ABC exceeds 
16 million, it cannot compile a BASIC program that contains a 
constant larger than 65,535. 

The blame again lies in the operating system. The Atari ROM 
routines that convert binary-coded decimal to "straight" binary 
only support numbers in the range from 0 to 65,535. 

It's very easy to get around this limitation. As an example, 
suppose your program uses a variable BIGNUM with a value of 
250,000. In regular BASIC, you would assign this value with 
the expression: 

BIGNUM = 250000 

ABC would disapprove of all those zeroes. But the expression: 
BIGNUM = 250*1000 

yields exactly the same result without making ABC unhappy. 
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Don't forget that the numbers in a DATA statement are not 
regarded as constants. So you can also use the expressions: 

100 READ BIGNUM 
110 DATA 250000 

and still satisfy both BASIC and ABC. 

4.7 Order Of Operations 

ABC handles division operations differently than Atari BASIC. 
Consider the following example (constants are used as a 
convenience): 

X = INT(5/3*2) 

The BASIC cartridge would first divide 5 by 3 (yielding a 
result of 1.66), multiply by 2 (with a result of 3.32) and then 
apply the INT function to obtain a final value of 3. But 
because the ABC interpreter deals only with whole numbers, it 
treats all division operations as an implicit INT(x/y) 
function. This means that ABC would interpret the above 
expression as: 

X = INT(lNT(5/3)*2) 

which evaluates to 2 instead of 3! 

To make the above example work in both standard and compiled 
BASIC, all that is needed is a simple inversion of terms: 

X = INT(5*2/3) 

This technique yields the desired result (3) in either case. 

Division is the only ABC operation that does not conform to 
Atari BASIC. Multiplication, addition and subtraction are 
performed in the normal manner. 

4.8 Unsupported Arithmetic Operators 

Only one arithmetic operator is not supported by the ABC 
compiler: the exponentiation operator "A." This operation is 

easily simulated (with greater speed) by using sequential 
multiplications. 


4.9 Unsupported BASIC Statements 

Once an Atari BASIC program has been translated into P-Code, it 
cannot be accessed by the BASIC cartridge. For this reason, 
compiled programs must not try to use the loading, saving and 
editing functions supported by the cartridge. In addition, 
because ABC does not employ floating-point math, the DEG and 
RAD statements have no meaning to the interpreter, 

ABC will not compile a BASIC program that contains any of the 
following statements: 


BYE 

CLOAD 

CONT 

CSAVE 

DEG 

DOS 

ENTER 

LIST 

LOAD 

LPRINT 

NEW 

RAD 

RUN 

SAVE 


4.10 

Break Key Handling 





When you hit the BREAK key during the execution of a normal 
Atari BASIC program, the program STOPs at the current line 
number and returns to the cartridge for the READY prompt. 

A compiled program has no cartridge to return to, so hitting 
the BREAK key does not stop the program unless the key was 
struck during an I/O operation. This forces an Error #128 
(Break Key Abort) which, unless TRAPped, causes the program to 
terminate. 

You can avoid problems with the BREAK key by disabling it with 
appropriate POKEs. Refer to the Atari Technical Reference 
Notes for more information on controlling the BREAK key. 

4.11 Subroutines And FOR/NEXT Loops 

When using ABC, it's important to keep track of how you exit 
subroutines and FOR/NEXT loops. In the following example: 

100 FOR I = 1 TO 100 

110 IF I = 50 THEN GOTO 130 

120 NEXT I 

130 PRINT "Loop aborted." 

the lack of a POP statement would probably confuse ABC when the 
loop index reached 50. The correct method is: 
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110 IF I = 30 THEN POP : GOTO 130 

This is good programming practice even in a non-ABC environment. 

The ABC interpreter is designed to handle no more than 64 
outstanding GOSUBs and/or FOR/NEXT loops simultaneously. If 
you manage to write a BASIC program that requires greater stack 
depth than this, congratulations I 

4.12 Arrays And Strings 

ABC does not use the same memory allocation method for arrays 
and strings as Atari BASIC. Consequently, programs that take 
advantage of BASIC's array and string allocation structure will 
not operate correctly when compiled. The ADR() function will, 
however, always return correct values. 

Consult Section 6.3 of this manual for more information on 
ABC’s memory allocation scheme for arrays and strings. 

4.13 Timing Loops 

BASIC programmers often use "do-nothing" FOR/NEXT loops to 
obtain time delays. These usually appear in the form: 

100 FOR DELAY = 1 TO 100 
110 NEXT DELAY 

You will be in for a shock if you compile and run the above 
instructions. ABC will execute the loop so rapidly that the 
delay will seem to disappear! 

The best way to write a controllable time delay for ABC is to 
use one of the Atari’s built-in hardware timers. The operating 
system changes the value of memory location 20 every l/60th of 
a second. By PEEKing this location in a FOR/NEXT loop, you can 
obtain precise time delays that will work correctly in both the 
BASIC and compiled versions of your software. 


The following time-delay subroutine can be appended to any 
BASIC program: 

1000 REM * ABC TIME DELAY SUBROUTINE 

1010 REM * Set the value of variable JIFFIES equal to 
1020 REM * the desired time delay in 60ths of a second. 

1030 REM * Then perform a GOSUB 1000 to obtain delay. 

1040 FOR DELAY = 1 TO JIFFIES 
1050 TICK = PEEK(20) 

1060 IF TICK = PEEK(20) THEN 1060 
1070 NEXT DELAY 
1080 RETURN 

To get a 5-second time delay with this method, you could write: 

100 REM * This is the body of your program. 

110 JIFFIES = 60*5 : GOSUB 1000 
120 REM * You just waited 5 seconds. 

Section 5 
Advanced Usage 

The following information is included for advanced programmers 
who may want to alter the default properties of the ABC 
compiler. Software authors who wish to distribute their 
compiled programs should also read this section. 

5•1 Changing The Load Address 

The ABC compiler normally produces code that is loaded at 
memory address $2600 (hex notation). This default address is 
derived from the run-time interpreter that is automatically 
loaded by the compiler (see Section 3). You can obtain an 
alternative load address by choosing a different run-time 
interpreter when the ABC compiler is run. 

Immediately after the ABC copyright message is displayed, the 
compiler scans the console switches for one second. If you 
press the OPTION key during this period, ABC will not proceed 
to load the $2600 interpreter. Instead, it will ask you for 
the name of one of the other interpreters included on your ABC 
disk. Respond with "INTERP.Xnn" where nn is the high byte of 
the load address in hex. For example, if you wanted a load 
address of $1F00, answer the prompt with "INTERP.X1F." 
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To find out which run-time interpreters are available on your 
ABC disk, enter DOS and use menu option "A" (directory) to 
examine the list of "INTERP" files. Contact Monarch Data 
Systems if you need an interpreter with a specific load address. 

5.2 Gen e rating Relocatable Code 

When producing software for commercial distribution, it’s a 
good idea to make the code relocatable to assure compatibility 
with different memory configurations. Your ABC disk includes a 
special utility called "MKRELO" that can be used to produce a 
compiled, fully relocatable version of your Atari BASIC 
programs. 

The code-generating technique used by MKRELO is unusual. It 
requires that you compile your BASIC source program twice , 
using different load addresses. MKRELO then compares the two 
disk files and produces a third version of the program which 
can be loaded at any address. 

The following procedure illustrates the proper use of MKRELO. 

It assumes that you have SAVEd a BASIC program called 

"GAME.BAS" on a source disk which also contains DOS 2.OS. Make 

sure there is plenty of free space on the source disk. 

a. Boot your ABC working disk along with the default ($2600) 
interpreter as described in Section 3. 

b. Respond to the prompt for the BASIC source filename 
("GAME.BAS" or just "GAME" in this example). 

c. Respond to the prompt for a destination filename, say 
"GAME.X26." 

d. When the first compilation is completed, replace the ABC 
working disk into Drive #1. Press the START key and 
immediately press and hold the OPTION key until you receive 
the prompt for an interpreter filename. Respond with 
"INTERP.X1F." 

e. After the compiler reads the $1F00 interpreter into RAM, 
replace the BASIC source disk and provide the source 
filename again ("GAME.BAS"). Then give ABC a destination 
filename that is different from the one used for the first 
compilation ("GAME.X1F," for instance). 

f. When the second compilation ends, return to DOS by pressing 
the SELECT key. Re-insert the ABC disk and use DOS option 
"L" to load and automatically run the MKRELO program. 
Replace the program disk when the MKRELO title appears. 


g. MKRELO will ask for the names of the two files created by 
the previous compilations. Respond with "GAME.X26" for the 
first prompt and "GAME.X1F" for the second prompt. 

h. You will now be asked for the filename of the final, 
relocatable program. Respond with a suitable title (e.g.; 
"GAME.REL") and press RETURN. 

i. MKRELO takes a while to finish because it compares the 
files one byte at a time. Once the process is completed, 
re-enter DOS by pressing the SELECT key. To load and run 
your relocatable program , use DOS option "L" and respond 
with the name of the file created by MKRELO. 

Section 6 
Technical Notes 

This section provides various technical details about the ABC 
compiler and the P-code it produces. 

6.1 Error Checking 

Most program conditions that require monitoring are checked 
during run-time. However, one specific condition that is not 
checked is subscript values . Any negative or out-of-bounds 
subscript will cause the ABC interpreter to behave in an 
unpredictable manner. We decided not to check subscripts 
because it saves execution time, and it was assumed that your 
source programs would be debugged before compilation. 

6.2 Low Memory Usage 

The ABC run-time interpreter uses all page zero locations from 
$80 and $C2 hex, inclusive. The standard BASIC line number and 
error number locations are supported. However, other BASIC 
zero-page variables (such as the high address pointer and 
symbol table pointer) are not supported. Page six ($600-$6FF) 
is fully available for USR routines and other purposes. 

6.3 Memory Allocation 

Compiled programs initially set the OS variable APPMHI ($0E-0F) 
to the end of the loaded program module. During the course of 
program execution, the value of APPMHI is automatically 
adjusted upward for the following reasons: 
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Input Statem e nt Buffe r. 

The first INPUT statement causes allocation of a 255-byte 
buffer. 

GOSUB and FOR Stack . 

The first GOSUB or FOR statement causes allocation of a 
128-byte stack. 

DIM Statements . 

Each DIMensioned numeric array requires nine bytes of control 
information plus three additional bytes per array element. 
DIMensioned string variables require nine bytes of control 
information plus one byte for each string character. 

Applications may allocate memory by adjusting APPMHI upward, 
but to be compatible with the BASIC cartridge you should work 
from MEMTOP ($2E5—2E6) downwards. It 1 s also a good idea to 
execute all DIM statements, a loop or GOSUB and an INPUT 
statement before allocating memory to make sure there’s enough 
room for ABC to work comfortably. 


Section 7 
Error Handling 

7.1 Compilation Errors 

Most of the error messages that can result from a compilation 
error are self-explanatory. However, there are two types of 
messages that require some explanation. 

If your BASIC source program includes an illegal statement or 
function, the compiler will display a coded message number that 
indicates which type of statement or function caused the 
error. A list of error message numbers and their corresponding 
statement/function follows. 
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7.2 Ill 


Statement Messag es 


Code 

_# 

Statement Name 

Code 

_# 

Statement Name 

4 


LIST 

5 


ENTER 

14 


BYE 

15 


CONT 

19 


DEG 

22 


NEW 

24 


LOAD 

25 


SAVE 

33 


RAD 

37 


RUN 

46 


DOS 

51 


LPRINT 

52 


CSAVE 

53 


CLOAD 

7.3 

Ille 

gal Function Messages 




Code 

_# 

Function Name 

Code 

± 

Function Name 

68 


ATN 

69 


COS 

71 


SIN 

72 


RND 

74 


EXP 

75 


LOG 

76 


CLOG 

77 


SQR 

7.4 

Run- 

Time Errors And Program 

Terminate on 




Only one type of message can result from a run-time error. 

This message displays a standard Atari BASIC error number along 
with the original BASIC line number that produced the P-code 
where the error occurred. You will also see a menu which 
allows you proceed in various ways by pressing a console key: 

OPTION Reboot entire system 

SELECT Return to DOS 

START Re-run the stopped program 

The above menu will also appear if a BASIC END command is 
encountered, or if the interpreter runs out of instructions to 
execute. 
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Warranty Information 


Monarch Data Systems warrants to the original purchaser that 
this Monarch Data Systems program diskette (not including the 
computer programs) shall be free from any defects in materials 
or workmanship for a period of 90 days from the original date 
of purchase. If a defect is discovered during this 90-day 
warranty period, and you have timely validated this warranty, 
Monarch Data Systems will repair or replace the diskette at 
Monarch Data System's option, providing that the diskette and 
proof of purchase are delivered or mailed, postage prepaid, to 
Monarch Data Systems. 

This warranty shall not apply if the diskette: 

Has been misused, or shows signs of excessive wear; 

Has been damaged by the playback equipment, or; 

If the purchaser causes or permits the diskette to be 
serviced or modified by anyone other than Monarch Data 
Systems. 

Any applicable implied warranties, including warranties of 
merchantability or fitness, are hereby limited to 90 days from 
the original date of purchase. Consequential or incidental 
damages resulting from a breach of any applicable express or 
implied warranties are hereby excluded. 

Notice 


All Monarch Data Systems computer programs are distributed on 
an "as is" basis, without warranty of any kind. The entire 
risk as to the quality and performance of such programs lies 
with the purchaser. Should the programs prove defective 
following their purchase, the purchaser and not the 
manufacturer, distributor or retailer assumes the entire cost 
of all necessary servicing or repair. 

Monarch Data Systems shall have no liability or responsibility 
to a purchaser, customer or any other person or entity with 
respect to any liability, loss or damage caused or alleged to 
have been caused directly or indirectly by computer programs 
sold through Monarch Data Systems. This includes but is not 
limited to any interruption of service, loss of business or 
anticipatory profits or consequential damages resulting from 
the use or operation of such computer programs. 

The provisions of the forgoing warranty are subject to the laws 
of the state in which the diskette is purchased. Such laws may 
broaden the warranty protection available to the purchaser of 
the diskette. 



